上一篇講到：要有一個檢查機制來防止知識庫充斥小錯誤，這個檢查機制就是 Lint

那這篇要講的是 Lint 的實做，首先

Lint 不會寫在 CLAUDE.md，而且要有明確觸發機制。

什麼時候觸發？

「檔案有改動」時觸發，但又不是改動瞬間觸發

我們可以理解為，老師收到學生作業後，要對這份作業做一次審閱。

寫完交出後才審閱，而不是學生每寫一筆老師就去拍桌

「你再寫一次你試試看！」不是這樣。

用 Git 協助審查

第九篇 已經把 Git 導入，我們就用 Git 來做檢查，這樣做我們可以直接確認「改了什麼」，並且檢查時機也更明確簡單。

因為對於 Git 來說，改動 = commit，以這個邏輯為基礎，Lint 的觸發時機就是「commit 的時候檢查」。

這樣比起想到才檢查還是什麼定期檢查來得可靠得多，講得簡單點就是

每次檢查一點點，比起出問題後檢查一大點輕鬆。

其次，跟 Git commit 一起做還有一個好處：改壞了可以直接復原

所以我的 Lint 會跟 Git commit 綁在一起。

檢查什麼？

上一篇有列出概念提出者 Karpathy 的檢查內容清單，也提了我對於該清單的想法，這邊講具體檢查了什麼。

四項主要邏輯，如果有人想用可以複製貼上給 Agent 討論，記得確認觸發時機，因為我這裡沒列出來，實際內容我會在後面的篇章弄一個「公開站」出來當作範例分享，這裡做個小預告。

1. 唯讀來源不能被竄改：你會有一個「只進不改」的原始素材資料夾（我的是 raw/）。
   在這個只進不改的資料夾，如果有內容被修改，直接判斷為異常；
   只有「搬到別的分類」或是「單純新增的檔案」這種操作才允許。

2. 孤兒頁面：掃描整個 wiki 的所有雙向連結（wikilink），找出「沒有任何一頁連進來」的頁面。
   索引頁、日誌這類本來就不需要被連入的頁面為例外。

3. 死鏈：解析頁面裡所有連結語法，確認每個連結指向的頁面是否有效。

4. Frontmatter 格式檢查：有改動的頁面，檢查必填欄位齊不齊全、欄位值有沒有落在你自訂的允許範圍內、日期格式一不一致。這項只驗證「格式對不對」，不驗證「內容對不對」。

任一項出狀況就停下來回報，不要自己決定修正方式就直接送出 commit。

以上就是這篇的全部內容。

寫稿時間 9/16，剛剛完成一次大型版本更新

本來是一邊寫文章，一邊重新審視當下的 Lint

審視到一半覺得當下的 Lint 機制稍微有點不穩定，於是上網問了一下。

然後就發現所謂的 Harness Engineering。而且其中一塊說的就是我整個系列一直想處理，但處理不好的問題。

「AI 對於規範、規則的執行不完整、有瑕疵」。

原先我採用「把規則寫清楚」的方向去改寫我的文件。

把每一條規則磨得更精確、更可執行，然而這個做法從根本上就錯了。

因為：CLAUDE.md、SKILLS 從來不是規範，而是餵給 LLM 的上下文。

把規則寫清楚，AI 看起來會照做，那麼如果上下文同時有十條規則呢？

AI 沒有機制知道「現在該不該套用這句話」。

在必要的時刻，將必要的內容 Load 進 context，這件事我一直沒處理好，這也是 Harness Engineering 在處理的事情（之一）

這也是這個系列接下來要調整的內容。

這篇原本要說的 Lint 實做，包括觸發時機、用 Git 協助審查、以及實際審查內容仍然成立，如果有想自己來的讀者還是可以參考。

但是真正的實做，容許我再延後。